Persist counterparty_claimable_outpoints out of channel_monitor#4461
Persist counterparty_claimable_outpoints out of channel_monitor#4461TheBlueMatt wants to merge 8 commits intolightningdevkit:mainfrom
Conversation
When a splice locks in, consumers need to know which previous funding outpoint was spent. Add a new field to Event::ChannelReady to surface this information: - spent_funding_txo: the previous funding outpoint consumed by the splice (None for initial channel funding) The field uses an odd TLV tag (3) for backward compatibility. Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Introduce two new events i.e. PersistClaimInfo and ClaimInfoRequest. PersistClaimInfo: Indicates that [ClaimInfo] may be durably persisted to reduce `ChannelMonitor` in-memory size. ClaimInfoRequest: Used to request [ClaimInfo] for a specific counterparty commitment transaction.
Introduces two new functions in the chainmonitor:
* `provide_claim_info` - is called in response to a `ClaimInfoRequest`
to provide the necessary claim data that was previously persisted using
the `PersistClaimInfo` event.
* `claim_info_persisted` - should be called after `ClaimInfo` is persisted
via the `PersistClaimInfo` event to confirm that the data is durably
stored.
Also introduces tracking of transactions which spend a commitment
transaction we're waiting on claim info for so that we can replay
them once we receive the claim info.
Original commit by G8XSU <3442979+G8XSU@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When we're waiting for claim info for a counterparty-broadcasted revoked commitment transaction, we confused our claimable `Balance` logic. Here we fix that, also including a new `Balance` to ensure that a `ChannelMonitor` which is waiting on claim info can not be pruned. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Indicates that a [`ClaimInfo`] for a specific counterparty commitment transaction must be supplied to LDK if available.
Indicates that [`ClaimInfo`] may be durably persisted to reduce `ChannelMonitor` in-memory size.
|
👋 Hi! This PR is now in draft status. |
While downstream code can always ignore `Event::PersistClaimInfo`, the generation of them can be somewhat expensive, so we thus allow downstream logic to disable them entirely here. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
TheBlueMatt
force-pushed
the
2026-01-new-monitor-offload
branch
from
dd0662a to
a09467c
Compare
| handler(ev).await | ||
| { | ||
| if !self.offload_claim_info { | ||
| if let Event::PersistClaimInfo { .. } = &ev { |
There was a problem hiding this comment.
This should actually not be generated instead of simply filtered.
|
🔔 1st Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 3rd Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 4th Reminder Hey @jkczyz! This PR has been waiting for your review. |
|
🔔 5th Reminder Hey @jkczyz! This PR has been waiting for your review. |
There was a problem hiding this comment.
tested this in ldk-server that monitor size stayed constant after streaming some HTLCs and it claimed the outputs if a revoked commitment was seen onchain after the user provided the claim info.
I was reading the discussion here https://github.com/orgs/lightningdevkit/discussions/3050 and this event-based approach seems simple enough (although as you pointed out, I don't think the PersistClaimInfo should be created at all rather than ignored if offload_claim_info == false) but I'm still wondering why this approach was taken over the other option of LDK handling it with some sort of persistence trait. It was mentioned that with that approach it will block the block processing until the write finished but with async persistence and a notifier, the same flow as here could be achieved?
And for something time-sensitive like this, depending on persist trait internally handled by LDK seems less problematic than hoping the user sends back the claim info.
My opinion is not enough to move the needle but it feels like this should be entirely handled by LDK and not by the user. Also, this is only an issue for routing nodes with a lot of traffic so I understand being optional but in principle it sounds like a good idea for any node regardless of traffic to not have every HTLC from every revoked commitment in memory all the time?
4 participants
Rebase + rework of #3106